When a user administers a communication system, such as a Private Branch Exchange (PBX), the user may want to change multiple parameters of the communication system. Changing multiple parameters works fine as long as the parameters do not require a reboot of the communication system. However, if the user wants to change multiple parameters that each requires a reboot of the communication system, the system will be rebooted for each change of each re-bootable parameter. This can lead to extensive down time if multiple parameters cause the communication system to be rebooted for each parameter.
This problem becomes even more difficult to resolve when stateless protocols, such as Representational State Transfer (REST) are used. Because of REST's stateless nature, REST requires that each re-bootable parameter be sent using a separate message. Like as previously described, the communication system must be reboot each time a re-bootable parameter is changed.
To address this problem, one solution that uses REST is to maintain a local copy of the configuration information (e.g., re-bootable parameters). The changes are managed by the client. When the changes are complete, the changes are then pushed back to the server. The server can then reboot based on the changes. The problem with this solution is that the client becomes more complicated and more difficult to maintain. This thwarts the whole purpose of REST where the clients are designed to be simple.